Service-Oriented Computing: Key Concepts and Principles

ions for SOC We can view SOC in terms of several different cross-cutting levels of abstractions, ranging from those that concern services within an application to those that concern service applications interacting across enterprises. Let’s consider a typical surgery division in a large hospital. One challenge in such a setting would be to make the payroll, scheduling, and billing systems interoperate. Each system is quite complex, with its own user interfaces and databases, perhaps running on different operating systems. For obvious reasons, these systems must work together. Scheduling employees and operating rooms for surgery is complicated, for example, because schedules require frequent updating. A scheduling system must balance staff and equipment availability with unpredictable levels of surgical urgency and advance notice. The mechanisms for payroll are similarly complex — the payroll system must consider various kinds of overtime rules for different categories of labor, such as nurses, residents, consulting physicians, senior surgeons, radiologists, and so on — and rely to some extent on data from the scheduling system. Likewise, the billing system must also incorporate scheduling information. It is used not only to bill customers, but also to deal with medical insurance companies and government agencies (such as those for children, the elderly, retired government employees, and veterans). Agencies typically impose complex rules for valid billing and penalties for violations of these rules. Across the US, for example, different rules apply regarding how hospitals can bill for anesthesiologists’ efforts during surgeries. In some states, a senior anesthesiologist can supervise up to four junior (resident) anesthesiologists. This senior person thus time-shares his or her effort among four concurrent surgeries, whereas each junior person is dedicated to one. If an emergency arises, the law allows a fifth surgical procedure under the same senior anesthesiologist’s supervision, but the billing rate is severely reduced. Hospital systems provide services within an enterprise, exemplifying the abstraction level of intraenterprise interoperation. Similar examples can exist among enterprises, among software components, and between the application level of a system and its infrastructure level, as the following sections describe. Intraenterprise Abstraction Level If we look at just the interoperation aspects in our hospital example, we quickly see several hurdles to overcome. The first is connectivity among the applications, which protocols such as HTTP can readily ensure. The second is the ability of the various components to understand each other. XML, particularly XML Schema, can handle communication formatting, but it cannot decipher the meaning behind a given message. Meaning usually is not encoded explicitly; rather, it depends on how various systems process information, which means system integrators and developers must uncover and reconcile the interacting components’ intent. This reconciliation presupposes that accurate declarative information models exist. In practice, however, such models are often poorly maintained or simply do not exist. Developers must thus construct (or reconstruct) them at integration time. This process is further complicated by the fact that information models for different systems might describe different abstraction levels. Services can encapsulate component behavior at many levels, but still describe it in the same way, thus easing composition of the components. Because our hospital setting deals with legacy and other systems and applications that operate within the enterprise, various enterprise policies must readily authenticate and authorize the parties involved in different interactions. A service-oriented architecture (SOA), by requiring that policies be made explicit, can organizationally enforce compliance with these policies, thus simplifying the system’s management. 76 JANUARY • FEBRUARY 2005 www.computer.org/internet/ IEEE INTERNET COMPUTING Service-Oriented Computing Track Figure 1. Web services architectural model. As a basis for a service-oriented architecture, Web services models incorporate how Web services are advertised, discovered, selected, and used. Bind